Subject: Support for Connection Networks over switched data networks

From: "jim (j.) cobban" <[email-masked]>
Date: Tue, 9 May 1995 14:22:00 -0400

Connection networks (CN) are currently specified for networks which use IEEE
802 style addressing.  It is possible to use CN over media using other
addressing schemes, but only if a "LAN Emulation" layer is introduced.  The
rapid arrival of Asynchronous Transfer Mode (ATM) cell-switching as a network
infra-structure points out the limitations of this implementation.

>From a functional point of view any network which provides a universal
addressing scheme should be capable of implementing a CN.  That is if a
station can signal to other stations a media level address which can be
used to communicate with it by any other station, then the fundamental
requirement for implementing a CN is established.

Typical sub-network technologies to which this criterion applies include:

  - ATM SVC
  - X.25 SVC
  - Frame-Relay SVC
  - IP
  - CLNP

To clarify this there are obvious sub-networks to which the criterion does
not apply.  For example X.25 or Frame-Relay PVC do not satisfy the criterion
because they use local addresses which are not globally significant.  Public
Switched Telephone Network (PSTN) connections do not apply because although
global addressing is used, the individual stations have a connection limit of
ONE which therefore precludes them establishing any additional connections as
a result of learning the global address of another station.  However if each
PSTN station has a bank of modems which are members of a hunt-group, then
signalling hunt-group addresses would satisfy the requirement.

These networks can be utilized in "LAN Emulation" mode now.  There are
situations in which this is actually the natural mode.  For example if the
actual end-stations are attached to an IEEE 802 medium, and the switched
network is only a transport between LANs then it is probably more natural to
use the IEEE 802 addresses than the switched medium addresses.  An example of
this is the Frame-Relay Boundary Access Node implementation.  Another is the
Data Link Switching encapsulation over TCP/IP.

However if the end stations are natively attached to the switched data
network, then introducing an additional address translation is an
administrative overhead which decreases the competitiveness of APPN as a
solution for customer networking problems.

Another concern related to the use of switched data networks as a data link
transport is the mapping of class of service to the quality of service
capabilities of the data transport.  All of the example sub-network
technologies provide quality of service options, such as priority, or delay
selection.

APPN views each connection across a switched data network as a single hop.
It therefore feels that it is sufficient to deliver data to the link in
priority order.  However in a switched data network there will always be
at least two, and typically at least 3 or 4 hops over this connection.  As a
vendor of switched data networking equipment I can assure you that customers
do NOT find simple ingress priority/delay scheduling to be acceptable.  They
demand that the class of service be reflected all the way through the
underlying transport.

The existing class of service route selection algorithms do not address this
requirement.  There is no way to configure the transmission group
characteristics of multiple parallel links across a switched data network in
such a way as to ensure that TRS will uniquely assign different classes of
service to different links.  It is necessary to actually signal the requested
class of service in some way to the switched data network.

Some switched data networks permit multiple priorities of traffic to share a
single virtual circuit.  Others do not.  It is desireable to leave that
question to the underlying network, rather than modelling it in APPN.   This
is desireable because:

  1) to minimize the number of transmission groups in the topology data base,
     and consequently the amount of topology database update traffic.
  2) to avoid modifying the current CN model which supports only a single
     connection between each pair of stations across the CN.
  3) avoid modification of TRS and SS to understand details of QoS for each
     data link type.

A number of other concerns have been raised with respect to use of switched
data networks for CN.  These include variations in transmission group
characteristics depending upon distance and closed user groups among others.
I believe that in practice these are manageable.  For example if the customer
tries to implement a CN across a network where closed user groups inhibit
connectivity, then the customer should reengineer either the CUGs or the CNs.
Note that the existing architecture does permit multiple CNs on a single
interface.  The variability of metrics was not used as a justification for
not implementing CN on Token-Ring, even though a Token-Ring network could
include locations which are attached across remote bridges.

Signalling
----------
At present when a node joins a connection network it presents a Transmission
Group Descriptor Control Vector (X'46') with a MAC/SAP subfield X'82'.  This
vector is stores in the topology data base.  When route selection determines
that the originating station and the destination station are both on the same
connection network, then the TGDCV is sent to the originating station.  The
originating station then uses this control vector to request DLC to establish
a new link connection.

In order to support switched data networks as CNs the first requirement is to
define additional CV46 subfields for signalling additional addressing
schemes.  The nucleus of this work has already been done for DLUR.

  - TR
    subfield X'91' explicitly identifies the subnetwork as TRN
    subfield X'93' DSAP (non-canonical)
    subfield X'94' DMAC (non-canonical)
  - ETHERNET
    subfield X'91' explicitly identifies the subnetwork as ETHERNET
    subfield X'93' DSAP (canonical)
    subfield X'94' DMAC (canonical)
  - X.25 SVC
    subfield X'91' identifies the subnetwork as X25SVC
    subfield X'94' protocol id (optional)
    subfield X'A5' provides the X.25 (1992) called address.
  - Frame-Relay SVC
*   subfield X'91' identifies the subnetwork as FRSVC
*   subfield X'93' destination (E.164) address
  - ATM
*   subfield X'91' identifies the subnetwork as ATMSVC
*   subfield X'93' destination (E.164) address
  - IP (note this requires definition of an encapsulation for SNA/TCP or UDP/IP)
*   subfield X'91' identifies the subnetwork as IP
*   subfield X'xx' IPv4 address or
*   subfield X'xx' IPv6 address 
  - CLNP (note: this requires definition of an encapsulation for
	  SNA/TP0 or 4/CLNP)
*   subfield X'91' identifies the subnetwork as CLNP
*   subfield X'xx' NSAP

Implementation Suggestion
-------------------------
The following discussion is not part of the requested architecture amendment.
It demonstrates the technical feasibility of the proposed amendment by 
discussing one possible implementation.

In existing implementations, which follow the design suggestions in the APPN
architecture, CS is aware of the IEEE 802 addressing scheme for SATF ports.
That is because while these implementations pass structureless media
addresses over the NOF-CS interface and the CS-DLC interface, a structured
CV46 SF82 address is passed over the SS-CS interface in the activate route.
CS therefore contains code to translate between the structured address of
the SS-CS interface to the unstructured address of the CS-DLC interface.  

DLUR is also forced to be aware of the translation between structured and
unstructured media addresses because it must also translate between CV46s
received from DLUS and the unstructured addresses to be signalled to the
individual DLCs.

It is proposed that all media addressing and QoS knowledge should be
concentrated in the DLCs and the management application user interface.
Addressing would always be signalled between all internal processes using the
CV46 formats, as discussed above.  This removes all knowledge of media
characteristics from CS and DLUR.

The desired class of service characteristics, including priority and delay
sensitivity, should be signalled in each DLC_MU on the PC-DLC interface.
This permits the DLC to translate between APPN class of service requirements
and the QoS capabilities of the underlying medium.  Some of this is
relatively straightforward to implement.  The DLC_MU signal which is sent on
the PC-DLC interface is derived from an MU signal on the SC/HS-PC interface.
The MU signal contains the session priority.  The default target delay,
throughput, and other characteristics could be derived at session start time
by extracting them from the first row of the selected COSTAB entry.  It is
the responsibility of the DLC to translate between the APPN characteristics
and the medium dependent signalling.  For APPC/LU 6.2 there has been
discussion that the desired characteristics could be selected explicitly at
transaction start time instead of being derived by default from the named
class of service.  If the explicitly requested characteristics did not fit
into any existing session, a new session pair would need to be established.

COS to QoS Mapping for Switched Data Networks
---------------------------------------------
There are many different underlying transports with widely varying
characteristics.  In the architecture model a single transmission group can
carry traffic belonging to more than one COS.  This is not a change from the
current architecture.  What is a change is that the requirement that the
transmission group delivers all PIUs end-to-end in the same order as they are
received is relaxed.  In its place is the looser restriction that all PIUs
with the same class of service and priority are delivered in order.  This is
an option which was described in the subarea SNA architecture, although never
implemented.  Since all PIUs within a session have the same class of service
and priority, they will maintain relative order, and as a consequence session
protocols will not break.

Existing applications request a particular class of service by specifying a
Logon Mode Name which references a named class of service.  Future
applications, for ATM exploitation, may explicitly request specific
transmission group characteristics at transaction start time.  These explicit
characteristics would override the named class of service.  It is proposed
that the actual TG characteristics attributes as currently defined, with
their existing encodings, should form the basis for specifying class of
service explicitly.  Additional characteristics, for example duration of
request, could be added.

One possible implementation of this is for PC to include in the DLC_MU signal
the session priority and the desired TG characteristics.  The DLC would use
these characteristics to select an existing VC, or to establish a new VC if
there were no suitable existing one.  Although the APPN TG characteristics
are encoded in a SNA specific way, I feel that there are obvious mappings to
the QoS characteristics of the various switched data networks.

---

From: Steve Berl <[email-masked]>
Date: Tue, 09 May 95 18:02:30 PDT

Thanks for the excellent presentation of these ideas. I agree with you
about the principles involved. I particularly like the idea of passing
the session priority in the the individual PIUs as they are passed
from PC to DLC. This solves the problem that I was trying to present
at the ATM BOF related to multiple parallel TGs on the same VC to
allow for multiprotocol prioritization within a single VC. If the DLC
was allowed to reorder the PIUs over a single TG, the other
requirement goes away.

A few fine points:

1) I think that PSTN networks make fine connection networks. You
suggested that they don't because many machines only have a single
connection to the network. I think that ISDN BRI with 2 channels, or
ISDN PRI with 24 channels are good examples of when it would make
sense to have a connection network over the phone. 

2) In the proposal for the CV46 subfields, you left out the subfield
X'93' DSAP for Frame Relay and ATM SVC connections. This would be
required for RFC1490 (BNN) or RFC1483 support.